It's not necessarily a breaking change, if all of the same paths are still available through num::foo.

The travis scripts will need to be updated to make sure all tests are run across all subcrates. Some of that is already extracted into separate shell scripts, so if it starts getting long we could pull the entire script: section into a real master script.

@cuviper I have changed some traits (i.e. content of Num trait was moved to the FromStrRadix) so it can break some apps.

No, it is not necessary. I will extract this.

Łukasz Jan Niemier

Dnia 16 lut 2016 o godz. 19:18 Josh Stone [email protected] napisał(a):

OK, I hadn't looked that closely since it's a WIP. FromStrRadix sounds
like a reasonable but orthogonal change. Is it really necessary for the
split? Otherwise I'd do that separately.
—
Reply to this email directly or view it on GitHub.

☔ The latest upstream changes (presumably ebed675) made this pull request unmergeable. Please resolve the merge conflicts.

I don't have a preference between this and my #174, except that it should happen sooner than later. Getting the traits into their own crate is already done, either here or there. If you get that merged separately, you can release the num-traits crate sooner. :-)

☔ The latest upstream changes (presumably #176) made this pull request unmergeable. Please resolve the merge conflicts.

@hauleth can we get the traits change landed and released sooner? My thinking is that this won't be a breaking change for any users so there's no need to delay landing any of it.

@hauleth

@cuviper I have changed some traits (i.e. content of Num trait was moved to the FromStrRadix) so it can break some apps.

Well, aside from this being breaking. I think it's orthogonal to the crate refactor and should be done either before or after the multi-crate change.

I should finish this later today, so You can expect release today (UTC+1 timezone).

@hauleth ! yay!

Aside, here's a neat way to test subpackages, pulling each lib.rs as a top-level [[test]].
https://users.rust-lang.org/t/cargo-test-internal-packages/5187/3

@cuviper this hack is nice, but not as it would satisfy me. It requires that root crate will have the same dependencies as all sub-crates. This is kind of no-go for us as I've splitted dependencies. What is more I want to make num-traits #![no_std] which would make whole testing suite fail. So currently our only solution is to use make.

@cuviper are we ready with this?

We need better subcrate descriptions, but otherwise I think it's good.

Will you bump the versions when you do this?

I have lots of ideas for Float that I'd like to explore if we have a new version. Ideally they would be in place in the first release of a new major version.

No bump yet, I think semver should be OK through this one.
(Please speak up if you think there's a break!)

I will finish it tomorrow. What is left is descriptions and publishing all packages.

I think that we should tag each of the subcrates independently via <subcrate name without num_* prefix>/<version>.

@hauleth Have you worked on those descriptions? If not, I can get to it tonight.

Here you are.

I'd prefer to keep a fuller description on the main num crate, but I'll tweak that myself.

I also just noticed that features aren't trickling down to subcrates correctly. For example, enabling serde at the top doesn't enable it in bigint. (which is broken anyway, missing extern crate serde;)

@cuviper I know no solution to push flags to sub crates. Maybe there should be an RFC for that.

I don't think there is a solution if the feature name is the same name as a dependency in the same crate. Otherwise you can forward like this:

[features]
serde = ["num-bigint/serde"]   # Requires same feature from dependency num-bigint

It is not conditionally forwarding.

This issue is semi related, isn't it? rust-lang/cargo#1286

Ah, but the top-level num crate itself doesn't actually need any of those external dependencies (rand, rustc-serialize, serde). So perhaps they can be left as abstract dependencies there, and then it should forward correctly, right?

Then for instance rational optionally uses bigint, but since the actual crate is named num-bigint, I think expanding num-rational/bigint may work. We may need default-features = false in the top Cargo.toml's rational section to allow fine control.

Should be fixed now.

Let's merge the beast. I can try to publish tonight, if you don't get to it first.
May want to get #182 in there too - it's a simple regression fix.

@homu r+ 58b5fe5

⚡ Test exempted - status

This is all published now.